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Abstract 

This  document  describes  a  new  architecture  that  ex¬ 
ploits  Semantic  Web  technologies  for  supporting  perva¬ 
sive  context-aware  systems.  This  architecture  called  Con¬ 
text  Broker  Architecture  (CoBrA)  differs  from  other  archi¬ 
tectures  in  using  the  Web  Ontology  Language  OWL  for  mod¬ 
eling  ontologies  of  context  and  for  supporting  context  rea¬ 
soning.  Central  to  our  architecture  is  a  broker  agent  that 
maintains  a  shared  model  of  context  for  all  computing  en¬ 
tities  in  the  space  and  enforces  the  privacy  policies  defined 
by  the  users  when  sharing  their  contextual  information.  We 
describe  the  use  of  CoBrA,  its  associated  ontologies,  and 
its  privacy  protection  mechanism  in  an  intelligent  meeting 
room  prototype. 


1.  Introduction 

The  Semantic  Web,  described  by  Tim  Berners-Lee  et.  al. 
[2],  is  an  extension  of  the  current  web  in  which  informa¬ 
tion  is  given  well-defined  meaning,  better  enabling  comput¬ 
ers  and  people  to  work  in  cooperation.  A  key  difference  be¬ 
tween  the  Semantic  Web  and  the  present  Web  lies  in  the 
representation  of  information.  In  the  present  Web,  the  rep¬ 
resentation  is  meant  for  machines  to  process  information 
at  the  syntax  level.  In  the  future  Semantic  Web,  however, 
the  representation  allows  machines  to  process  and  reason 
about  information  at  the  semantic  level.  In  this  paper,  we 
describe  a  new  approach  that  explores  the  use  of  Seman¬ 
tic  Web  technologies  (i.e.,  languages,  logic  inferences,  and 
programming  tools)  in  building  an  architecture  for  support¬ 
ing  context-aware  systems  in  smart  spaces  (e.g.,  intelligent 
meeting  rooms,  smart  vehicles,  and  smart  houses). 

Context  is  any  information  that  can  be  used  to  charac¬ 
terize  the  situation  of  a  person  or  a  computing  entity  [7]. 
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Previous  research  [17,  28,  19]  have  viewed  location  infor¬ 
mation  as  an  important  aspect  of  context.  We  believe  in  ad¬ 
dition  to  the  location  information,  an  understanding  of  con¬ 
text  should  also  include  information  that  describes  system 
capabilities,  services  offered  and  sought,  the  activities  and 
tasks  in  which  people  and  computing  entities  are  engaged, 
and  their  situational  roles,  beliefs,  desires,  and  intentions. 

The  dynamic  nature  of  a  smart  space  environment  cre¬ 
ates  great  challenges  for  developing  context-aware  systems. 
We  believe  some  of  the  critical  research  issues  are  context 
modeling,  context  reasoning,  knowledge  sharing,  and  user 
privacy  protection.  To  address  these  issues,  we  propose  an 
agent-oriented  architecture  called  Context  Broker  Architec¬ 
ture  that  uses  the  Semantic  Web  languages  to  model  ontolo¬ 
gies  of  context,  to  reason  with  context  in  a  smart  space,  and 
to  define  a  policy  language  for  users  to  control  the  sharing 
of  their  contextual  information. 

The  rest  of  this  document  is  organized  as  the  follow¬ 
ing:  Section  2  gives  a  brief  overview  of  the  Semantic  Web 
and  the  Web  Ontology  Language  OWL.  In  Section  3  we  de¬ 
scribe  the  rationale  behind  our  Semantic  Web  approach  to 
building  a  new  architecture  for  context-aware  systems.  Sec¬ 
tion  4  presents  the  design  of  CoBrA  and  its  use  case  sce¬ 
nario  in  an  intelligent  meeting  room.  Section  5  describes 
our  preliminary  work  on  prototyping  EasyMeeting,  an  in¬ 
telligent  meeting  room  system  that  builds  on  the  design  of 
CoBrA.  Discussions  of  the  related  work  and  concluding  re¬ 
marks  are  given  in  Section  6  and  Section  7,  respectively. 

2.  An  Overview  of  the  Semantic  Web 

The  Semantic  Web  is  a  vision  in  which  web  pages  are 
augmented  with  information  and  data  that  is  expressed  in 
a  way  that  facilitates  its  understanding  by  computing  ma¬ 
chines  [6].  The  current  human-centered  web  is  largely  en¬ 
coded  in  HTML,  which  focuses  largely  on  how  text  and  im¬ 
ages  would  be  rendered  for  human  viewing.  Over  the  past 
few  years  we  have  seen  a  rapid  increase  in  the  use  of  XML 
as  an  alternative  encoding,  one  that  is  intended  primarily 
for  machine  processing.  The  machine  which  process  XML 
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documents  can  be  the  end  consumers  of  the  information  or 
they  can  be  used  to  transform  the  information  into  a  form 
appropriate  for  human  understand  (e.g.,  as  HTML,  graph¬ 
ics,  and  synthesized  speech).  As  a  representation  language, 
XML  provides  essentially  a  mechanism  to  declare  and  use 
simple  data  structures,  and  thus  it  leaves  much  to  be  de¬ 
sired  as  a  language  in  which  to  express  complex  knowledge. 
Enhancements  to  basic  XML,  such  XML  Scheme,  address 
some  of  the  shortcomings,  but  still  do  not  result  in  an  ad¬ 
equate  language  for  representing  and  reasoning  about  the 
kind  of  knowledge  essential  to  realizing  the  Semantic  Web 
vision. 

A  goal  of  the  Semantic  Web  initiatives  sponsored  by 
the  World  Wide  Web  Consortium  (W3C)  is  to  develop 
languages  that  are  adequate  for  representing  and  reason¬ 
ing  about  the  semantics  of  information  on  the  Web.  The 
Web  Ontology  Language  OWL  is  the  latest  standard  pro¬ 
posed  by  the  Web-Ontology  Working  Group.  The  OWL  lan¬ 
guage  builds  on  XML’s  ability  to  define  customized  tagging 
schemes  and  RDF’s  flexible  approach  to  represent  data  [16]. 
Due  to  space  limitation,  in  this  section  we  describe  some  of 
the  OWL  language  constructs  and  show  how  they  are  used 
to  define  ontologies. 

OWL  is  a  language  for  defining  and  instantiating  ontolo¬ 
gies.  An  ontology  is  a  formal  explicit  description  of  con¬ 
cepts  in  a  domain  of  discourse  (or  classes),  properties  of 
each  class  describing  various  features  and  attributes  of  the 
class,  and  restrictions  on  properties  [24], 

The  normative  OWL  exchange  syntax  is  RDF/XML. 
OWL  ontologies  are  usually  placed  on  web  servers  as  web 
documents,  which  can  be  referenced  by  other  ontologies 
and  downloaded  by  applications  that  use  ontologies.  Fig¬ 
ure  1  shows  an  example  of  an  OWL  ontology  encoded  in 
RDF/XML. 

The  definitions  in  our  example  ontology  has  two  parts. 
The  first  part  is  a  set  of  classes  and  properties  that  describe 
people,  devices,  and  the  ownership  relations  between  them. 
The  second  part  is  a  set  of  class  individuals  that  represent 
specific  people  and  devices  in  some  imaginary  domain  dis¬ 
course. 

The  class  definition  in  our  example  begins  with  the  con¬ 
cept  Person  and  Device.  A  class  represents  a  set  of  indi¬ 
viduals  in  the  domain  (i.e..  Person  represents  a  set  of  in¬ 
dividual  person.  Device  represents  a  set  of  individual  de¬ 
vice).  PDA  and  Cellphone  are  two  other  classes  that  rep¬ 
resent  a  set  of  individual  PDA  and  cellphone  in  our  domain. 
They  are  both  subclasses  of  the  class  Device.  Note  that, 
by  default,  every  individual  in  the  OWL  world  is  a  member 
of  the  class  owl :  Thing.  Thus,  all  of  our  defined  classes 
are  implicitly  subclasses  of  owl :  Thing. 

Properties  in  OWL  lets  us  assert  general  facts  about 
the  members  of  classes  and  specific  facts  about  individuals 
[26],  A  property  is  a  binary  relation.  Two  types  of  proper- 


<rdf:RDF 

xmlns=“http://example.org/devices#” 

xmlns:exd=“http://example.org/devices#” 

xmlns:owl="http://www.w3.org/2002/07/owl#'' 

xml  ns :  rdfs= "http  ://www.  w3 .  org/2000/0 1 /rdf-sche  m  a#" 

xmlns:rdf="http://www.w3.org/1 999/02/22-rdf-syntax-ns#" 

xmlns:xsd=“http://www.w3.org/2001/XMLSchema#”> 

<owl:Ontology  rdf:about=“http://example.org/devie”> 

<rdfs:comment>An  ontology  about  people  and  devices</rdfs:comment> 
<rdfs:label>An  Example  Ontology</rdfs:label> 

</owl:Ontology> 

<owl:Class  rdf:ID="Person7> 

<owl:Class  rdf:ID="Device"/> 

<owl:Class  rdf:ID="Cellphone"/> 

<rdfs:subClassOf  rdf:resource="#Device"/> 

</owl:Class> 

<owl:Class  rdf:ID="PDA7> 

<rdfs:subClassOf  rdf:resource="#Device7> 

</owl:Class> 

<owl:DatatypeProperty  rdf:ID="name"> 

<rdfs:domain=  "http://www.w3.Org/2002/07/owl#Thing7> 

<rdfs:range  rdf:resource=  "http://www.w3.Org/2001/XMLSchema#string7> 
</owl :  DatatypeProperty> 

<owl:ObjectProperty  rdf:ID="ownedBy"> 

<rdfs:domain  rdf:resource="#Device"/> 

<rdfs:  range  rdf:  resou rce="#Person"/> 

</owl:ObjectProperty> 

<owl:ObjectProperty  rdf:ID="owns"> 

<owl:inverseOf  rdf:resource="#ownedBy"/> 

</owl  :ObjectProperty> 

<Person  rdf:ID="P1"> 

<name  rdf:datatype=“&xsd;string”>Harry  Chen</name> 

<owns  rdf:resource="#D17> 

</Person> 

<Person  rdf:ID="P2"> 

<name  rdf:datatype=“&xsd;string”>Joe  Smith</name> 

</Person> 

<Cellphone  rdf:ID="D1"> 

<name  rdf:datatype=“xsd;string”>Harry's  Blue  Phone</name> 

</Cellphone> 

<PDA  rdf:ID="D2"> 

<name  rdf:datatype=“&xsd;string”>Blue  Knight</name> 
cownedBy  rdf:resource="P2"/> 

</PDA> 

<rdf:RDF> 

Figure  1.  An  example  of  OWL  classes  and 
properties  of  a  simple  ontology. 


ties  are  distinguished:  datatype  properties  and  object  prop¬ 
erties.  The  former  is  relations  between  instances  of  classes 
and  RDF  literals  and  XML  Schema  datatypes.  The  latter  is 
relations  between  instances  of  two  classes. 

When  defining  a  property,  its  domain  and  range  can  be 
specified.  Specifying  the  domain  of  a  property  asserts  that 
the  domain  value  of  the  property  must  belong  to  a  speci¬ 
fied  class.  Specifying  the  range  of  a  property  asserts  that 
the  range  value  of  the  property  must  belong  to  a  specified 
class  or  to  a  specified  data  type. 

In  our  example,  the  name  property  is  defined 


as  a  type  of  the  datatype  property.  It  has  domain 
owl :  Thing  and  range  http  :  / /www  .  w3  .  org/2001  / 
XMLSchema#string.  This  asserts  that  any  individual 
member  of  the  owl :  Thing  class  can  have  a  name  prop¬ 
erty  with  some  string  value.  For  example,  the  individual  P 1 
is  instantiated  with  the  name  string  “Harry  Chen”,  and  indi¬ 
vidual  D1  is  instantiated  with  the  name  string  “Harry’s  Blue 
Phone”. 

There  are  two  object  properties  in  our  ontologies.  First, 
the  ownedBy  property  has  domain  Device  and  range 
Person.  This  asserts  that  the  ownedBy  property  can  re¬ 
late  a  device  to  its  owner  (e.g.,  the  device  D2  is  owned 
by  the  person  P2).  The  owns  property  is  defined  as  an  in¬ 
verse  of  the  ownedBy  property.  This  asserts  that  for  every 
triple  (X,  ownedBy,  Y ),  there  is  a  triple  (Y,  owns, 
X)  and  vice  versa  (since  the  inverse  relation  is  symmet¬ 
ric).  Thus,  from  the  example,  since  we  know  (PI,  owns, 
D1 ),  we  can  conclude  (Dl,  ownedBy,  P 1 ) ,  and  simil- 
iarly  since  we  know  (D2,  ownedBy,  P2 ),  we  can  con¬ 
clude  (P2,  owns,  D2)  also  holds. 

3.  Why  Semantic  Web 

A  key  requirement  for  realizing  context-aware  systems  is 
to  give  computer  systems  the  ability  to  understand  their  sit¬ 
uational  conditions.  To  achieve  this,  it  requires  contextual 
information  to  be  represented  in  ways  that  are  adequate  for 
machine  processing  and  reasoning.  We  believe  the  Seman¬ 
tic  Web  languages  are  well  suited  for  this  purpose  for  the 
following  reasons: 

•  RDF  and  OWL  are  knowledge  representation  lan¬ 
guages  with  rich  expressive  power  that  are  adequate 
for  modeling  various  types  of  contextual  information, 
e.g.,  information  associated  with  people,  events,  de¬ 
vices,  places,  time,  and  space.  Ontologies  expressed 
these  languages  provide  a  means  for  independently  de¬ 
veloped  context-aware  systems  to  share  context  knowl¬ 
edge,  minimizing  the  cost  of  and  redundancy  in  sens¬ 
ing. 

•  Because  context  ontologies  have  explicit  representa¬ 
tions  of  semantics,  they  can  be  reasoned  by  the  avail¬ 
able  logic  inference  engines.  Systems  with  the  ability 
to  reason  about  context  can  detect  and  resolve  incon¬ 
sistent  context  knowledge  that  often  result  from  imper¬ 
fect  sensing. 

•  The  Semantic  Web  languages  can  be  used  as  meta¬ 
languages  to  define  other  special  purpose  languages 
such  as  communication  languages  for  knowledge  shar¬ 
ing,  policy  languages  for  privacy  and  security  [10],  A 
key  advantage  of  this  approach  is  better  interoperabil¬ 
ity.  Tools  for  langages  that  share  a  common  root  of 


constructs  can  better  interoperate  than  tools  for  lan¬ 
guages  that  have  diverse  roots  of  constructs.  For  ex¬ 
ample,  the  existing  trust  infrastructure  for  mobile  de¬ 
vices  [22]  could  exploit  the  Semantic  Languages  as  a 
means  to  support  independently  developed  Semantic 
Web  gadgets  [15]. 

4.  Context  Broker  Architecture 

The  core  of  CoBrA  is  a  specialized  server  entity  called 
context  broker.  In  a  smart  space,  a  context  broker  has  the 
following  responsibilities:  (i)  provide  a  centralized  model 
of  context  that  can  be  shared  by  all  devices,  services,  and 
agents  in  the  space,  (ii)  acquire  contextual  information  from 
sources  that  are  unreachable  by  the  resource-limited  de¬ 
vices,  (iii)  reason  about  contextual  information  that  cannot 
be  directly  acquired  from  the  sensors  (e.g.,  intentions,  roles, 
temporal  and  spatial  relations),  (iv)  detect  and  resolve  in¬ 
consistent  knowledge  that  is  stored  in  the  shared  model  of 
context,  and  (v)  protect  user  privacy  by  enforcing  policies 
that  the  users  have  defined  to  control  the  sharing  and  the 
use  of  their  contextual  information. 

4.1,  An  Intelligent  Meeting  Room  Scenario 

The  design  of  CoBrA  is  aimed  to  support  context-aware 
systems  in  smart  spaces.  The  following  is  a  typical  use  case 
scenario  of  CoBrA  in  an  intelligent  meeting  room  system: 

R210  is  an  intelligent  meeting  room  with  RFID  sensors 
embedded  in  the  walls  and  furniture  for  detecting  the  pres¬ 
ence  of  the  users’  devices  and  clothing.  As  Alice  enters  the 
room,  these  sensors  inform  the  R2 10  broker  that  a  cellphone 
belonging  to  her  is  present,  and  the  broker  adds  this  fact  in 
its  knowledge  base. 

As  she  sits,  the  agent  on  Alice’s  Bluetooth  enabled  cell¬ 
phone  discovers  R210’s  broker  and  engages  in  a  “hand 
shake”  protocol  (e.g.  authenticates  agent  identities  and  es¬ 
tablishes  trust  [10])  after  which  it  informs  the  broker  of  Al¬ 
ice’s  privacy  policy.  This  policy  represents  Alice’s  desires 
about  what  the  broker  should  do  and  includes  (i)  the  con¬ 
textual  information  about  Alice  that  the  broker  is  permitted 
or  prohibited  from  storing  and  using  (e.g.,  yes  to  her  loca¬ 
tion  and  roles,  no  to  the  phone  numbers  she  calls),  (ii)  other 
agents  that  the  broker  should  inform  about  changes  in  her 
contextual  information  (e.g.,  keeping  Alice’s  personal  agent 
at  home  informed  about  her  location  context),  and  (iii)  the 
permissions  for  other  agents  to  access  Alice’s  contextual  in¬ 
formation  (e.g.,  all  agents  in  the  meeting  room  can  access 
Alice’s  contexts  while  she  is  in  the  room). 

After  receiving  Alice’s  privacy  policy,  the  broker  creates 
a  profile  for  Alice  that  defines  rules  and  constraints  the  bro¬ 
ker  will  follow  when  handling  any  context  knowledge  re¬ 
lated  to  Alice.  For  example,  given  the  above  policy,  the  pro- 


file  for  Alice  would  direct  the  broker  (i)  to  acquire  and  rea¬ 
son  about  Alice’s  location  and  activity  contexts,  (ii)  to  in¬ 
form  Alice’s  personal  agent  at  home  when  Alice’s  contexts 
change,  and  (iii)  to  share  her  contexts  with  agents  in  the 
meeting  room. 

Knowing  Alice’s  cellphone  is  currently  in  R210  and  hav¬ 
ing  no  evidence  to  the  contrary,  the  broker  concludes  Alice 
is  also  there.  Additionally,  because  R210  is  a  part  of  the 
Engineering  building,  which  in  turn  is  a  part  of  the  Cam¬ 
pus,  the  broker  concludes  Alice  is  located  in  the  Engineer¬ 
ing  building  and  on  the  Campus.  These  conclusions  are  as¬ 
serted  into  the  broker’s  knowledge  base. 

Following  the  profile,  the  broker  informs  Alice’s  per¬ 
sonal  agent  of  her  whereabouts.  On  receiving  this  informa¬ 
tion  about  Alice,  her  personal  agent  attempts  to  determine 
why  Alice  is  there.  Her  Outlook  calendar  has  an  entry  in¬ 
dicating  that  she  is  to  give  a  presentation  on  the  Campus 
about  now,  so  the  personal  agent  concludes  that  Alice  is  in 
R210  to  give  her  talk  and  informs  the  R210  broker  of  it’s  be¬ 
lief. 

On  receiving  information  about  Alice’s  intention,  the 
R210  broker  shares  this  information  with  the  projector 
agent  and  the  lighting  control  agent  in  the  ECS  210.  Few 
minutes  later,  the  projector  agent  downloads  the  slides  from 
Alice’s  personal  agent  and  sets  up  the  projector,  the  light¬ 
ing  control  agent  dims  the  room  lights. 

4.2.  Context  Broker 

Figure  2  shows  the  design  of  a  context  broker.  In  smart 
spaces,  context  brokers  are  assumed  to  be  running  on 
resource-rich  stationary  computers  that  are  embedded  in  the 
environment  (e.g..  Mocha  PC1 ).  In  our  preliminary  work,  all 
computing  entities  in  a  smart  space  are  presumed  to  have 
priori  knowledge  about  the  presence  of  a  context  broker.  In 
the  future  design,  we  will  attempt  to  use  one  of  the  avail¬ 
able  service  discovery  infrastructure  (e.g.,  Jini,  UPnP)  to 
improve  system  flexibility. 

Our  centralized  design  of  the  context  broker  is  motivated 
by  the  need  to  support  small  devices  that  have  relatively 
limited  resources  available  for  context  acquisition  and  rea¬ 
soning.  With  the  presence  of  a  broker,  small  devices  such 
as  cellphones,  PDA  and  watches  can  offload  their  burdens 
of  managing  context  knowledge  onto  a  resource  rich  server 
entity,  including  reasoning  with  context,  detecting  and  re¬ 
solving  inconsistent  context  knowledge.  Furthermore,  in  an 
open  and  dynamic  environment,  users  may  desire  their  per¬ 
sonal  contextual  information  to  be  kept  in  private.  A  cen¬ 
tralized  management  of  context  knowledge  makes  easy  to 
implement  privacy  protection  and  information  security. 


1  http : //www . cappuccinopc . com/mochap4 . asp 
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Figure  2.  A  context  broker  acquires  contex¬ 
tual  information  from  heterogeneous  sources 
and  fuses  it  into  a  coherent  model  that  is  then 
shared  with  computing  entities  in  the  space. 


A  centralized  broker  can  be  the  “bottle-neck”  in  a  dis¬ 
tributed  system,  creating  a  single  point  of  failure  in  the  sys¬ 
tem.  To  address  this  problem,  we  plan  to  investigate  and 
develop  a  fault-tolerance  approach  based  on  the  Persistent 
Broker  Team  [13]  approach.  Our  idea  is  to  introduce  a  team 
of  brokers  in  that  each  member  has  the  responsibility  to  en¬ 
sure  at  least  one  broker  is  available  to  provide  services.  In 
the  case  when  the  number  of  available  team  members  falls 
below  a  pre-defined  threshold  (e.g.,  some  broker  becomes 
unreachable  due  to  network  failures),  the  remaining  active 
team  members  will  attempt  to  recruit  or  instantiate  new  bro¬ 
kers.  In  a  broker  team,  the  Joint  Intention  protocol  [23]  can 
be  used  to  bring  about  the  mutual  beliefs  of  the  team  states 
and  team  commitments. 

A  context  broker  has  the  following  four  functional  com¬ 
ponents: 

1.  Context  Knowledge  Base:  a  persistent  storage  of  the 
context  knowledge.  It  provides  a  set  of  API’s  for  other 
components  in  a  broker  to  access  the  stored  knowl¬ 
edge.  It  also  contains  the  ontologies  of  a  specific  smart 
space  (e.g.,  the  ontologies  of  an  intelligent  meeting 
room)  and  some  heuristic  knowledge  associated  with 
the  space  (e.g.,  a  company’s  daily  operation  hours  are 
between  9:00  AM  to  5:00  PM;  no  person  can  be  physi¬ 
cally  present  at  two  different  meeting  locations  during 
the  same  time  interval). 

2.  Context  Reasoning  Engine:  a  reactive  inference  en¬ 
gine  that  reasons  over  the  stored  context  knowledge. 
Two  types  of  inferences  can  take  place  in  this  en¬ 
gine:  (i)  inferences  that  use  ontologies  to  deduce  con¬ 
text  knowledge,  and  (ii)  inferences  that  use  heuristic 


knowledge  to  detect  and  resolve  inconsistent  knowl¬ 
edge. 

3.  Context  Acquisition  Module:  a  library  of  procedures 
that  forms  a  middle-ware  abstraction  for  context  ac¬ 
quisition.  The  role  of  this  component  is  similar  to  the 
role  of  the  Context  Widgets  in  the  Context  Toolkit  [7], 
which  is  to  shield  the  low-level  sensing  implementa¬ 
tions  from  the  high-level  applications. 

4.  Policy  Management  Module:  a  set  of  inference  rules 
that  deduce  instructions  for  enforing  user  policies. 
Some  rules  are  defined  for  deciding  the  right  permis¬ 
sions  for  different  computing  entities  to  share  a  partic¬ 
ular  piece  of  context  information,  and  some  rules  are 
defined  for  selecting  the  recipients  to  receive  notifica¬ 
tions  of  context  changes. 

5.  Prototyping  an  Intelligent  Meeting  Room 

To  demonstrate  the  feasibility  of  our  Context  Broker  Ar¬ 
chitecture,  we  are  using  CoBrA  to  prototype  an  intelligent 
meeting  room  system  called  EasyMeeting,  which  provides 
assistants  to  meeting  speakers,  audiences,  and  organizers 
based  on  their  situational  needs.  EasyMeeting  is  an  exten¬ 
sion  to  Vigil,  a  smart  space  system  that  we  have  previously 
developed  [25].  Security  is  the  main  focus  in  Vigil.  A  role 
based  access  control  mechanism  is  implemented  in  Vigil  to 
allow  users  control  to  the  permissions  to  access  different 
services  using  policies.  Vigil  differs  from  other  frameworks 
in  using  logic  inference  rules  to  reason  about  the  rights  of 
different  users. 

Vigil  has  shown  great  promises  in  building  flexible  and 
secure  smart  spaces  [25],  However,  it  lacks  the  necessary 
support  for  context-aware  systems.  To  improve  upon  Vigil, 
in  EasyMeeting  we  use  OWL  to  represent  context  ontolo¬ 
gies,  and  we  exploit  a  context  broker  to  support  context  rea¬ 
soning. 

In  the  rest  of  this  section,  first,  we  overview  the  ontolo¬ 
gies  that  we  have  developed  to  support  EasyMeeting  and 
their  potential  role  in  the  context  reasoning,  second,  we  dis¬ 
cuss  how  the  Rei  policy  language  can  be  used  to  facilitate 
user  privacy  protection  in  CoBrA,  and  third,  we  describe  a 
prototype  implementation  of  the  context  broker. 

5.1.  Ontologies 

We  have  developed  a  set  of  ontologies  called  COBRA- 
ONT  [3]  for  modeling  context  in  an  intelligent  meeting 
room.  In  this  document,  we  described  the  version  0.3  of 
the  COBRA-ONT  that  defines  typical  concepts  and  rela¬ 
tions  for  describing  physical  locations,  time,  people,  soft¬ 
ware  agents,  mobile  devices,  and  meeting  events.  In  this 


version  of  the  ontology,  there  are  88  classes  and  125  prop¬ 
erties,  which  are  grouped  into  six  distinctive  ontology  doc¬ 
uments2 

5.1.1.  Reasoning  with  the  Physical  Location  Ontology 

Understanding  the  context  associated  with  physical  lo¬ 
cations  is  extremely  important  in  context-aware  systems. 
An  ontology  of  physical  locations  in  COBRA-ONT  in¬ 
cludes  the  descriptions  of  places  with  identifiable  geo¬ 
graphic  boundaries  (e.g.,  rooms,  buildings),  places  with 
spatial  properties  (e.g.,  atomic  places,  compound  places), 
and  places  with  temporal  properties  (e.g.,  meeting  rooms 
during  the  working  hours,  offices  on  a  public  holiday). 
An  ontology  of  the  physical  location  context  includes  geo¬ 
graphic  attributes,  typical  social  norms  of  a  particular  place, 
objects  that  occupy  or  are  contained  in  a  particular  space, 
and  events  that  occur  at  a  particular  place. 

In  our  ontology  the  class  Place  is  the  parent  class 
of  all  represented  place  classes.  Subclasses  of  Place  are 
Campus,  Building,  Room,  Hallway,  Parkinglot, 
Restroom,  and  Conf erenceRoom,  which  are  concepts 
of  places  with  identifiable  geographic  boundaries. 

COBRA-ONT  divids  subclasses  of  Place  into  types 
of  either  atomic  place  or  compound  place,  which  are  con¬ 
cepts  of  places  with  spatial  properties.  Atomic  places  (e.g., 
Conf  erenceRoom,  Hallway)  are  places  that  cannot  be 
defined  to  spatially  subsume  other  places.  Compound  places 
(e.g..  Campus,  Building)  are  places  that  can  be  defined 
to  spatially  subsume  other  atomic  or  compound  places. 

Spatial  containment  inference  is  a  type  of  reasoning  with 
location  context.  Let  us  consider  the  scenario  described  in 
Section  4.1.  As  Alice  enters  the  conference  room,  informa¬ 
tion  acquired  from  the  sensors  in  the  room  may  lead  the  con¬ 
text  broker  to  conclude  that  Alice  is  in  the  room  R210.  Be¬ 
cause  the  broker  has  an  ontology  of  the  associated  location 
(e.g.,  the  Engineering  building  spatially  subsumes  the  room 
R210,  and  the  Campus  spatially  subsumes  the  Engineering 
building),  the  broker  can  draw  new  conclusions  about  Al¬ 
ice’s  location  context,  e.g.,  Alice  is  located  in  the  Engineer¬ 
ing  building,  Alice  is  located  on  the  Campus. 

Reasoning  with  the  spatial  containment  relation  can  also 
help  the  broker  to  detect  errors  in  sensing.  Let  us  assume  in 
addition  to  the  location  ontology,  the  broker  also  has  some 
heuristic  knowledge  about  the  associated  location,  for  ex¬ 
ample,  “no  person  can  physically  present  at  more  than  one 
atomic  place  during  the  same  time  interx’al”.  When  coupled 
with  the  location  ontology,  this  knowledge  can  help  the  bro¬ 
ker  to  detect  if  there  is  any  inconsistency  about  a  user’s  loca¬ 
tion  context.  Imagine  that  due  to  sensing  errors,  some  sen¬ 
sors  falsely  detect  the  present  of  Alice  and  informs  the  bro¬ 
ker  that  she  is  located  in  the  parking  lot  A.  Since  Alice  is 


2  COBRA-ONT  ontology  documents  are  available  online  at  http :  // 
cobra . umbc . edu/ 


known  to  be  located  in  the  room  R210,  and  both  the  park¬ 
ing  lot  A  and  the  room  R210  are  atomic  places,  the  broker 
can  immediately  conclude  the  location  context  of  Alice  is 
inconsistent. 

5.1.2.  Reasoning  with  the  Device  Ontology  In  a  per¬ 
vasive  computing  environment,  devices  in  the  immediate 
vicinity  of  a  user  are  also  part  of  the  user’s  context.  Device 
context  can  include  basic  knowledge  about  the  device  pro¬ 
files  (e.g.,  does  a  particular  device  support  color  display?), 
the  device  ownership  relation  (e.g.,  who  is  the  owner  of  a 
particular  device?),  temporal  properties  associated  with  a 
device  (e.g.,  when  was  the  last  time  a  particular  device  has 
been  used?),  and  spatial  properties  associated  with  a  device 
(e.g.,  what  is  the  distance  between  a  particular  device  and 
the  room  in  which  its  owner  is  currently  in?). 

To  support  the  reasoning  with  device  profiles,  COBRA- 
ONT  includes  an  ontology  of  device  hardware  and  software 
profiles.  Part  of  this  ontology  is  adopted  from  the  FIPA  de¬ 
vice  ontology  specification  [8],  The  hardware  profile  ontol¬ 
ogy  includes  concepts  of  screen  displays  (e.g.,  screen  width 
and  length,  display  color  profile),  device  memory  (e.g., 
amount  of  memory,  memory  size  unit,  and  memory  us¬ 
age  type),  device  network  capability  (e.g.,  support  for  wire¬ 
less/wired  communications,  supported  network  interfaces). 
The  software  profile  ontology  includes  concepts  of  device 
operating  systems  and  supported  computing  platforms. 

By  extending  the  device  profile  ontology,  COBRA-ONT 
provides  an  ontology  of  mobile  devices.  The  goal  is  to  de¬ 
fine  specific  ontology  classes  that  represent  different  types 
of  mobile  devices  and  properties  that  are  associated  with 
these  devices.  Represented  types  of  mobile  devices  are 
SonyEricsson  T68i,  SonyEricsson  T800,  and  Palm  Tung- 
stenT.  Defined  properties  include  the  hardware  and  software 
profiles  of  these  devices  and  additional  relations  that  asso¬ 
ciate  the  devices  with  people.  For  example,  the  ownedBy 
property  expresses  the  relation  between  a  device  and  its 
owner,  and  the  usedBy  property  expresses  the  relation  be¬ 
tween  a  device  and  its  user.  Both  of  these  properties  have 
inverse  properties  (i.e.,  the  owns  and  uses  properties). 

To  illustrate  how  reasoning  with  device  ontologies  can 
play  a  role  in  context-aware  systems,  let  us  consider  the  fol¬ 
lowing  use  case:  after  Alice  enters  the  meeting  room  R230, 
her  cellphone  presents  Alice’s  policy  to  the  context  broker 
in  the  room.  Assuming  the  context  broker  has  an  ontology 
of  the  device  that  sends  the  policy,  it  reasons  about  the  pro¬ 
file  of  the  device,  e.g.,  the  sender  is  a  type  of  SonyEricsson- 
T68i  cellphone,  and  its  Bluetooth  communication  supports 
the  OBEX  object  push  service  for  exchanging  vCard  con¬ 
tacts.  Knowing  the  device  profile,  the  context  broker  in¬ 
forms  all  meeting  services  that  could  take  advantage  of  this 
information,  e.g.,  a  contact  exchange  service  that  can  au¬ 
tomatically  push  new  contact  information  into  the  mobile 
devices  that  a  meeting  participant  carries.  Additionally,  the 


context  broker  reasons  about  the  person  who  owns  and  uses 
the  device  (e.g.,  Alice  is  the  owner  of  this  device,  and  no  ev¬ 
idence  shows  the  device  is  used  by  other  people).  Since  Al¬ 
ice’s  SonyEricsson  T68i  cellphone  is  the  room  R230  and  no 
evidence  to  the  contrary,  the  context  broker  concludes  Al¬ 
ice  is  also  in  the  room  R230. 

5.1.3.  Reasoning  with  the  Temporal  Ontology  Aspects 
of  context  can  also  include  temporal  relations.  To  support 
reasoning  with  time  and  temporal  relations,  COBRA-ONT 
adopts  the  DAML-time  ontology,  which  is  a  temporal  ontol¬ 
ogy  for  expressing  temporal  aspects  of  the  contents  of  web 
resource  and  for  express  time-related  properties  of  web  ser¬ 
vices  3.  The  DAML-time  ontology  in  COBRA-ONT  is  an 
OWL  version  of  the  original  DAML-time  ontology  that  is 
expressed  in  the  DAML+OIL  language. 

The  DAML-time  ontology  builds  around  a  set  of  ab¬ 
stract  temporal  entities  and  temporal  relation  axioms.  Our 
OWL  representation  of  the  ontology  defines  the  vocabular¬ 
ies  of  the  abstract  temporal  entities.  However,  it  does  not 
include  a  representation  of  the  temporal  relation  axioms  be¬ 
cause  the  present  OWL  language  does  not  have  direct  sup¬ 
port  for  expressing  axiomatic  rules.  Research  in  developing 
language  constructs  for  representing  rules  in  Semantic  Web 
languages  is  underway  [9], 

In  DAML-time  two  abstract  temporal  entity  classes  are 
Instant  and  Interval.  Both  are  subclasses  of  the 
TemporalEntity  class.  A  member  of  the  Instant 
class  represents  an  instant  of  time,  which  has  associated 
temporal  description  properties  that  represent  the  concepts 
of  second,  minute,  hour,  day,  month,  year,  and  time  zone. 
A  member  of  the  Interval  class  represents  a  time  inter¬ 
val  between  two  different  time  instants.  Properties  of  this 
class  include  beginOf  and  endOf,  which  define  the  be¬ 
ginning  time  (a  time  instant)  and  the  ending  time  (a  time  in¬ 
stant)  of  a  time  interval. 

A  type  of  relation  between  the  individuals  of  the 
TemporalEntity  class  is  temporal  ordering.  The  tem¬ 
poral  ordering  relation  can  be  expressed  in  the  before 
and  the  after  properties,  i.e.,  an  individual  of  the 
Instant  or  Interval  class  can  have  a  before  or 
after  property  value  of  another  individual  of  Instant 
or  Interval  class.  The  temporal  ordering  relation  can 
also  be  expressed  using  the  inside  and  time-between 
properties,  which  describes  a  time  instant  is  inside  of  a 
particular  time  interval,  and  a  time  interval  is  in  between 
of  two  different  time  instants,  respectively. 

The  DAML-time  ontology  defines  a  number  of  predi¬ 
cates  (properties)  for  linking  time  entities  to  events  in  the 


3  A  DAML  ontology  of  time,  http :  //www .  cs  .  rochester .  edu/ 
~ferguson/ daml/ daml- time- 2 002 08 30 . txt 


real  world4,  which  include  at  Time,  expressing  an  event 
occurs  at  a  particular  time  instant,  during,  express  an 
event  occurs  during  a  particular  time  interval,  and  holds, 
expressing  an  event  holds  at  a  particular  time  instant  or  dur¬ 
ing  a  particular  time  interval. 

To  illustrate  the  use  of  temporal  ontology,  let  us  consider 
the  following  use  case:  a  meeting  agent  informs  the  con¬ 
text  broker  that  a  meeting  is  scheduled  to  take  place  in  the 
room  R230  from  13:00  to  14:00  on  12/03/2003,  which  can 
be  represented  as  during  (meeting  (meeting023, 
time Interval ('2003-12-03T13:00:00' , 

'  2003-12-03T14  :  00  :  00'  )  )  )5,  and  Alice  is  one  of 
the  scheduled  meeting  attendees.  At  13:03,  an  RFID  sen¬ 
sor  informs  the  context  broker  that  it  detects  the  presence 
of  Alice’s  cellphone  in  the  room  R230.  Based  on  this  in¬ 
formation,  through  reasoning  the  context  broker  concludes 
Alice  is  also  located  in  the  room  R230,  which  can  be  rep¬ 
resented  as  atTime (locatedln (alice,  r230)  , 
time Inst ant ('2003-12-03T13:03:00'  )  ). 

Using  the  axiom  associated  with  the  predicate 
inside,  the  context  broker  infers  the  time  in¬ 
stant  '2003-12-03T13:04:00'  is  inside  of 
the  time  interval  ('  2003-12-03T13  :  00  :  00'  , 

'  2003-12-03T14  :  00  :  00'  ) .  Based  on  the  tem¬ 
poral  ordering  of  these  two  events,  the  context  bro¬ 
ker  believes  Alice  is  attending  a  meeting  at  13:03. 
Without  having  any  evidence  to  the  contrary,  the  con¬ 
text  broker  further  believes  Alice  is  likely  to  be  lo¬ 
cated  in  the  room  until  14:00,  which  can  be  repre¬ 
sented  as  during (locatedln (alice,  r230)  , 
time Interval ('2003-12-03113:03:00'  , 

' 2003-12-03T14 : 00:00')). 

We  recognize  that  the  described  logic  inferences  are 
rigid,  e.g.,  they  do  not  address  the  condition  in  which  a  per¬ 
son  is  temporarily  absent  from  the  meeting,  or  the  meeting 
is  ended  at  a  time  instant  that  is  earlier  than  the  scheduled 
end  time.  In  the  future,  we  plan  to  explore  abductive  reason¬ 
ing  [11]  as  a  means  to  improve  inference  flexibility. 

5.2.  User  Privacy  Protection 

To  protect  user  privacy  in  smart  spaces,  the  design  of  Co- 
BrA  follows  the  principle  of  proximity  and  locality  [14],  ex¬ 
ploiting  the  locality  information  of  the  users  for  enforcing 
access  restrictions  to  their  personal  information.  For  differ¬ 
ent  type  of  smart  spaces,  CoBrA  defines  different  special¬ 
ized  access  control  models  for  protecting  the  privacy  of  the 
users.  An  access  control  model  consists  of  a  set  of  infer¬ 
ence  rules  that  a  context  broker  uses  to  decide  the  permis¬ 
sion  for  revealing  a  users  contextual  information. 


4  Descriptions  of  events  are  assumed  to  be  defined  by  ontologies  that 
are  outside  of  the  DAML-time  ontology 

5  The  date/time  description  is  in  the  ISO  8601  Date  and  Time  format. 


As  different  users  in  the  same  smart  space  may  desire 
different  levels  of  privacy  protection,  CoBrA  allows  users  to 
modify  the  default  access  control  model  of  the  smart  space 
by  providing  their  own  privacy  policies.  A  privacy  policy 
(or  policy)  is  a  set  of  declarative  rules  that  a  user  defines 
to  restrict  the  access  to  his  personal  information.  For  exam¬ 
ple,  upon  entering  a  smart  space,  the  user  authenticates  his 
identity  and  informs  the  context  broker  of  his  privacy  pol¬ 
icy.  The  broker  then  reasons  about  the  policy  to  determine 
the  access  control  rules  that  are  imposed  by  the  policy.  If 
these  rules  differ  from  the  rules  in  the  default  access  con¬ 
trol  model,  the  broker  will  create  a  personalized  access  con¬ 
trol  model  of  the  user.  This  model  will  be  used,  instead  of 
the  default  model,  to  guide  the  brokers  reasoning  in  decid¬ 
ing  the  appropriate  permissions  to  reveal  the  users  contex¬ 
tual  information. 

5.2.1.  Privacy  Policy  Language  In  CoBrA,  the  represen¬ 
tation  of  the  privacy  policy  extends  the  Rei  policy  language 
[10].  Rei  is  a  policy  language  that  defines  a  set  of  ontol¬ 
ogy  concepts  for  modeling  rights,  prohibitions,  obligations 
and  dispensations  in  the  domain  of  security.  The  key  ad¬ 
vantage  of  using  Rei  to  develop  a  new  privacy  policy  lan¬ 
guage  is  in  its  built-in  support  for  the  modeling  of  security 
objects  (i.e.,  rights,  prohibitions,  obligations,  and  dispensa¬ 
tions)  and  its  ability  to  interoperate  with  the  Semantic  Web 
languages.  For  example, 

•  to  specify  a  projector  device  has  the  right  to  access  Al¬ 
ice’s  location  context  only  if  the  device  is  located  in 
the  same  room  as  Alice,  using  the  has  predicate  in 
Rei,  the  following  rule  can  be  defined: 

has (projector, 

right  (accessContext (alice, location)  , 
colocated (alice, pro jector) ) ) . 

•  to  prohibit  a  location  tracking  service  from  accessing 
Alice’s  location  context  when  the  service  is  not  authen¬ 
ticated  by  the  context  broker,  the  following  rule  can  be 
defined: 

has (locTracker, 

prohibition (accessContext (alice, location) , 
not (authBy (locTracker, broker) ) ) ) . 

Protecting  the  privacy  of  a  user  sometimes  means  to  hide 
the  details  of  certain  information  from  the  computing  enti¬ 
ties  in  the  environment.  The  Rei  language  provides  users  the 
necessary  constructs  to  define  rules  to  grant  or  deny  the  ac¬ 
cess  to  their  contextual  information.  In  order  to  give  users  a 
fine-grained  control  on  how  the  broker  can  share  their  con¬ 
textual  information,  we  introduce  additional  language  con¬ 
structs  to  allow  granularity  parameters  to  be  specified  for 
the  contextual  information.  For  example,  if  Alice  does  not 
want  other  people  to  know  the  specific  room  that  she  is  in, 
but  she  does  want  others  to  know  the  general  description  of 


her  whereabouts  (e.g.,  on  a  campus  or  in  a  building).  A  pol¬ 
icy  can  be  defined  as  the  following: 

has (broker, 

right (shareContext (alice, location) ) , 
granularity (location, raduis ( 1 , mile) ) . 

This  rule  states  that  the  broker  has  the  right  to  share  Al¬ 
ices  location  information  only  if  the  information  that  de¬ 
scribes  a  physical  location  that  has  the  geographic  radius 
larger  than  1  mile.  In  other  words,  if  some  service  asks  the 
broker  if  Alice  is  on  a  campus  that  spatially  subsumes  the 
room  that  Alice  is  in,  the  broker  will  reply,  yes,  but  if  some 
service  asks  the  broker  if  Alice  is  located  in  a  particular 
building  on  the  campus,  the  broker  will  reply,  unknown  (as¬ 
suming  the  geographic  radius  of  a  building  is  less  than  1 
mile). 

5.2.2.  Meta-Reasoning  with  Policies  In  a  pervasive  com¬ 
puting  environment,  the  ubiquitous  access  to  vast  amount 
of  information  creates  a  new  problem  for  user  privacy.  Al¬ 
though  users  can  define  policies  to  control  the  dissemination 
of  their  situational  information,  such  policies  cannot  always 
guard  against  the  possibility  of  others  to  deduce  the  private 
information  of  the  user  through  different  means  of  knowl¬ 
edge  acquisition  (e.g.,  inference,  data  mining).  In  the  design 
of  CoBrA,  we  attempt  to  address  the  problem  of  inference, 
which  is  to  develop  mechanisms  to  prevent  the  leaking  of 
information  that  could  potentially  be  used  to  deduce  a  users 
private  information.  Some  typical  examples  of  the  problem 
of  inference  are  the  following:  (i)  if  someone  knows  the 
home  phone  number  of  a  user,  it  is  possible  to  acquire  the 
mailing  address  of  the  user  by  looking  up  a  White  Page  ser¬ 
vice  on  the  Internet,  (ii)  if  someone  knows  the  email  address 
of  a  user  (e.g.,  someone@host.mil,  or  someone@host.gov), 
based  on  the  domain  name  part  of  the  email  address,  it  is 
possible  to  infer  that  the  user  probably  works  for  one  of  the 
US  government  agencies. 

To  address  the  problem  of  inference,  our  context  bro¬ 
ker  implementation  will  allow  special  meta-reasoning  rules 
to  be  configured  for  different  types  of  smart  spaces.  These 
meta-reasoning  rules  help  the  broker  to  decide  the  permis¬ 
sions  for  revealing  the  types  of  contextual  information  that 
is  not  explicitly  constrained  by  the  privacy  policies.  For  ex¬ 
ample,  (i)  if  a  user’s  policy  specifies  that  no  location  infor¬ 
mation  should  be  shared,  the  broker  will  attempt  to  keep  se¬ 
crete  of  users  daily  schedule  because  from  the  daily  sched¬ 
ule  it  is  possible  to  determine  the  whereabouts  of  the  user, 
(ii)  if  a  user’s  policy  specifies  that  his  home  address  should 
not  be  revealed,  the  broker  will  attempt  to  keep  secrete  of 
his  home  phone  number  because  it  is  possible  to  lookup  the 
corresponding  address  using  a  White  Page  service.  The  fol¬ 
lowing  is  an  example  of  the  meta-reasoning  rules  expressed 
in  Prolog: 

mayKnow (X, location (Y)  know (X, schedule (Y) ) . 
mayKnow (X, homeAdd ( Y) )  know (X, phoneNum (Y) ) . 


Figure  3.  In  our  prototype  system,  the  broker 
attempts  to  infer  the  location  contexts  of  de¬ 
vices  and  users.  An  user  model  is  dynami¬ 
cally  acquired  from  an  URL  specified  in  the 
received  user  policy. 


5.3.  A  Context  Broker  Prototype 

We  have  implemented  a  context  broker  prototype  to 
demonstrate  its  role  in  the  EasyMeeting  system.  Our  ob¬ 
jective  is  to  show  the  Semantic  Web  languages  are  ade¬ 
quate  for  dynamically  constructing  representations  of  con¬ 
text  information  acquired  from  sensors,  and  how  this  infor¬ 
mation  then  can  be  used  to  infer  additional  context  knowl¬ 
edge.  In  our  present  implementation,  a  context  broker  can 
reason  about  the  presence  of  people  and  device  in  an  intel¬ 
ligent  meeting  room. 

Figure  3  shows  the  design  layout  of  our  prototype  sys¬ 
tem.  Central  to  the  system  is  a  context  broker.  This  bro¬ 
ker  is  implemented  as  a  FIPA  compliant  agent  that  runs 
on  the  IADE  platform  (a  Java  library  for  building  FIPA 
compliant  agents)  [1].  The  broker  uses  the  Jena  Seman¬ 
tic  Web  Toolkit6  for  managing  and  manipulating  ontologies 
(e.g.,  dynamically  constructing  OWL  ontology  statements 
for  agent  communications,  manipulating  ontology  knowl¬ 
edge  that  is  stored  in  a  persistent  knowledge  base). 

RDQL  (RDF  Data  Query  Language)  is  used  in  the 
broker’s  reasoning  engine  to  access  the  stored  ontology 
knowledge.  Using  RDQL,  the  reasoning  engine  periodi¬ 
cally  queries  the  knowledge  base  for  the  presence  of  cer¬ 
tain  context  knowledge  (e.g.,  has  any  device  been  detected 
in  the  room,  who  is  the  owner  of  a  particular  device?). 
When  queries  return  matched  results,  the  broker  automat¬ 
ically  adds  new  assertions  about  the  local  context  into  its 
knowledge  base.  For  example,  if  queries  return  information 
about  the  presence  of  a  new  device  and  the  person  who  owns 
the  device,  then  the  broker  asserts  the  owner  of  the  device 
is  also  present  in  the  room. 


6  http : / / www . hpl . hp . com/ semweb/ jena . htm 


For  context  sensing,  the  context  broker  delegates  the 
tasks  to  other  sensing  agents  in  the  environment.  When  the 
broker  starts  on  a  hosting  JADE  platform,  it  finds  all  sens¬ 
ing  agents  that  are  registered  with  the  local  yellow  page 
service  (FIPA  Directory  Facilitator)  and  sends  a  FIPA  sub¬ 
scribe  message  to  these  agents,  requesting  to  be  notified 
about  context  changes.  In  our  prototype  system,  we  have 
implemented  a  sensing  agent  called  BT  Sensor,  which  is  re¬ 
sponsible  for  detecting  Bluetooth  OBEX  object  push  events 
that  are  initiated  by  the  mobile  devices.  As  a  mobile  device 
sends  an  OBEX  object  to  the  BT  Sensor  (e.g.,  a  SonyEric- 
sson  T68i  cellphone  sends  a  vNote  object  to  the  BT  Sen¬ 
sor),  the  BT  Sensor  agent  concludes  the  presence  of  the  de¬ 
vice  and  notifies  the  context  broker. 

Messages  sent  from  a  Bluetooth  device  to  the  BT  Sen¬ 
sor  agent  contains  a  FIPA  ACL  message  that  informs  the 
context  broker  of  a  user’s  background  information  (or  user 
model).  A  user  model  includes  a  privacy  policy  that  a  user 
defines  to  control  the  use  and  the  sharing  of  his/her  con¬ 
text  information.  Due  to  the  message  size  limitations  in  our 
Bluetooth  devices,  messages  sent  by  the  devices  contain  the 
URL  of  the  web  documents  that  have  complete  descriptions 
of  the  user  models.  The  representation  of  this  URL  informa¬ 
tion  is  expressed  in  a  RDF  statement  which  is  encoded  in 
N3  7,  for  example,  "agt :  HarryChen  agt :  aboutMe 
http://umbc.edu/hchen4/aboutMe.".  The  first 
term  agt :  HarryChen  is  a  subject  RDF  resource  that  de¬ 
fines  this  statement  is  about  the  user  Harry  Chen.  The  sec¬ 
ond  term  agt :  aboutMe  is  a  property  of  the  subject.  The 
last  term  is  the  value  of  the  property,  which  is  an  URL 
from  which  the  user  model  of  agt :  HarryChen  can  be 
retrieved. 

To  show  the  underlying  ontology  reasoning  in  the  bro¬ 
ker,  we  have  developed  a  web  application,  backed  by  the 
Apache  Tomcat  Server,  for  viewing  the  internal  knowledge 
base  of  the  context  broker.  In  future,  this  web  application 
will  include  administrator  functions  for  manging  a  context 
broker  (start,  shutdown  etc.). 

6.  Related  Work 

In  the  past,  a  number  of  system  architectures  have  been 
developed  to  support  pervasive  computing  such  as  the  Con¬ 
text  Toolkit  framework  [20],  Schilit’s  context-aware  archi¬ 
tecture  [21],  Cooltown  [12],  the  Active  Badge  System  [27], 
and  the  Intelligent  Room  [5].  These  systems  have  made 
progress  in  various  aspects  of  pervasive  computing  but  are 
weak  in  supporting  knowledge  sharing  and  context  rea¬ 
soning.  A  significant  source  of  this  weakness  is  their  lack 


7  Premier:  Getting  into  RDF  &  Semantic  Web  Using  N3.  http:  // 
www . w3 . org/2000/ 10/ swap /Primer 


a  common  ontology  with  explicit  semantic  representation 
[4,18], 

Key  differences  between  our  architecture  and  the  previ¬ 
ous  systems  are  the  following:  (i)  We  use  Semantic  Web 
languages  (i.e.,  RDF  and  OWL)  to  define  ontologies  of 
contexts,  providing  an  explicit  representation  of  contexts 
for  reasoning  and  knowledge  sharing.  In  the  previous  sys¬ 
tems,  contexts  are  often  implemented  as  programming  ob¬ 
jects  (e.g.,  Java  class  objects)  or  informally  described  in 
documentations,  (ii)  In  CoBrA  a  resource-rich  agent  (i.e., 
the  context  broker)  is  provided  to  manage  and  maintain  a 
shared  model  of  context  for  all  devices,  services  and  agents 
in  an  associated  space.  In  the  previous  systems,  individual 
entities  are  required  to  manage  and  maintain  their  own  con¬ 
text  knowledge,  (iii)  The  context  reasoning  in  CoBrA  gives 
context  brokers  the  ability  to  infer  new  context  knowledge 
(e.g.,  spatial  relations,  device  profiles)  that  cannot  be  eas¬ 
ily  acquired  from  the  physical  sensors.  In  the  previous  sys¬ 
tems,  contexts  acquired  from  the  sensors  are  presumed  to  be 
accurate  and  consistent,  (iv)  The  use  of  policies  in  CoBrA 
allow  users  to  control  their  contextual  information,  speci¬ 
fying  the  granularity  of  information  that  is  shared  by  the 
systems  and  choosing  recipients  to  receive  notifications  of 
their  context  changes.  In  preivous  systems,  acquired  con¬ 
textual  information  is  allowed  to  be  freely  share  by  all  com¬ 
puting  entities  in  the  environment,  which  could  potentially 
jeopardize  user  privacy. 

7.  Conclusion  &  Future  Work 

The  use  of  ontology  is  a  key  requirement  for  realizing 
pervasive  context-aware  systems.  Our  preliminary  research 
in  the  Context  Broker  Architecture  shows  the  Web  Ontol¬ 
ogy  Language  OWL  is  adequate  for  defining  ontologies  for 
supporting  context  reasoning  and  knowledge  sharing.  As 
the  Semantic  Web  technologies  (i.e.,  programming  libraries 
for  manipulating  ontologies  and  logic  inference  engines  for 
ontology  reasoning)  emerge,  we  believe  the  Semantic  Web 
will  create  new  research  opportunities  for  building  perva¬ 
sive  context-aware  systems. 

Based  on  COBRA-ONT,  at  present  we  are  working 
other  researchers  to  define  a  standard  ontology  for  sup¬ 
porting  pervasive  computing  applications8.  The  new  on¬ 
tology  called  Pervasive  Computing  Standard  Ontology 
(PERVASIVE-SO)  will  define  typical  concepts  and  rela¬ 
tions  for  representing  agent,  person,  device,  time,  space, 
event,  document,  and  policy.  Part  of  our  short  term  objec¬ 
tive  is  to  enhance  the  logic  inferences  in  the  context  broker 
using  abductive  reasoning  and  exploring  temporal  and  spa¬ 
tial  inferences.  Our  long-term  objective  is  to  deploy  an  in- 


8  The  ongoing  work  is  described  on  the  Semantic  Web  in  UbiComp  SIG 
homepage:  http :  / / pervasive  .  semanticweb .  org. 


telligent  meeting  room  in  the  newly  constructed  Informa¬ 
tion  Technology  and  Engineering  Building  on  the  UMBC 

main  campus. 
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